1. Field of the Invention
In general, the present invention provides a method, system and program product for recording and replaying target service interaction data. Specifically, the present invention allows a service interaction to be realistically simulated in a development environment.
2. Related Art
As computing technology becomes more advanced, a key area of development has been in Business-to-Business and Enterprise Integration Applications. In service-oriented applications, middle tier components are represented by services and processes. Services often access remote resources, such as Enterprise Information Systems (EIS). Some typical examples of an EIS are CICS, IMS, SAP, PeopleSoft, etc.
In a service-oriented application, client components (e.g., JAVA Beans, Enterprise JAVA Beans, processes, etc. {JAVA, JAVA bean and Enterprise JAVA bean are trademarks of Sun Microsystems Corp. in the U.S. and/or elsewhere}) do not execute EIS transactions directly. Rather, each EIS transaction is typically executed by invoking an operation defined by a target “service,” which is described by one or more Web Services Description Language (WSDL) files. These WSDL files capture the following information about the service: (1) port type, or interface describing the service operations, and the format of input and output data; (2) service bindings describing the address of the EIS system to connect to; and (3) operation bindings describing the name of the EIS function to execute, and additional system-specific information (e.g., protocol).
Service invocations are generally performed by a service invocation framework. Some examples of service invocation frameworks include International Business Machine Corp.'s Web Services Invocation Framework (WSIF) and JService container. The service invocation framework provides a level of indirection between the caller and the callee. The client component generally needs to be aware of the interface (port type) of the service, but not necessarily the binding used to invoke the service. To this extent, a typical service invocation using WSIF involves the following high-level steps: (1) client code registers the target service with WSIF-WSDL definition files are loaded; (2) WSIF looks up the required service provider based on the binding of the requested service; (3) WSIF uses the provider to create a dynamic port containing connection information; (4) client code uses the dynamic port to create input and output messages; (5) client code uses the dynamic port to create an operation instance; (6) client code prepares a message containing data that is used as input to the underlying transaction, and a message that is used to hold the results; (7) client code calls the execute( ) method of the operation instance, passing the input message as argument; and (8) client code processes the message that holds the transaction results.
Unfortunately, one of the key problems encountered during development of Business-to-Business and Enterprise Integration Applications involves unit testing and debugging of middle-tier components. Specifically, the EIS running production transactions should not be interfered with during the development process, otherwise side effects from interactions during the development process are captured in the production system. The same logic applies to other types of resources accessed by a given service such as a remote EJB. During the lifecycle of a service-oriented application, it will go through the following phases: (1) initial creation; (2) unit testing; (3) integration testing; (4) certification testing; (5) deployment to production environment; (6) monitoring and problem/determination in the production environment; and (7) iterative development to fix problems, and subsequent re-deployment.
During phases 6 and 7, to perform problem determination and iterative fixes, developers need to work in an environment that very closely resembles the production environment. Setting up duplicate EIS's with a replicated subset of production data is frequently a very difficult, time-consuming, and expensive process. It involves setting up duplicate hardware and software, and placing additional workload on key technical staff. In addition, it is very difficult to test and demo new applications in a field environment because the required EIS environment is not portable. Conventional logging often does not provide sufficient information to precisely identify the problem, and it can be impossible to validate the fix without re-deployment.
In view of the foregoing, there exists a need for production phase EIS and Service interactions to be recorded in such a way that they can be replayed during future development phases. Specifically, a need exists for a system in which realistic service interactions can be simulated during application development. To this extent, there is a need to be able to simulate interactions using actual production data as opposed to sample data.